微前端框架之wujie与micro

 在我的上一篇文章中，初步判定wujie比micro-app的性能相对来说更加好。但是作为一个严谨的搬砖者，是不允许这种没有数据支撑的结论的，所以今天我特意再写一篇文章详细地比较一下这两个框架之前的差异。

 wujie将子应用的js注入主应用同域的iframe中运行，iframe是一个原生的window沙箱，内部有完整的history和location接口，子应用实例instance运行在iframe中，路由也彻底和主应用解耦，可以直接在业务组件里面启动应用。

 micro-app借鉴了WebComponent的思想，通过CustomElement结合自定义的ShadowDom，将微前端封装成一个类WebComponent组件，从而实现微前端的组件化渲染。

 在我把项目改造成微前端框架的过程中，路由的改造过程是问题最多的部分，所以在改造前这块必须优先考虑。

 wujie：在内部有完整的history和location接口，子应用实例instance运行在iframe中，路由也彻底和主应用解耦，可以直接在业务组件里面启动应用。并且劫持iframe的history.pushState和history.replaceState实现路由同步，基本上不需要对路由适配进行改造（这也可能是我更喜欢wujie的一个原因）

 micro-app：由于主应用跟子应用共用一个路由，所以在主应用是hash路由的情况下，子应用也必须是hash路由(也不需要太担心，毕竟hash路由使用的场景还是挺多的)

 wujie：由于iframe的存在，多个子应用之间同时运行基本没什么问题。

 micro-app：同样的，主应用是hash路由的情况下，子应用是不能存在history路由的。

 在改造微前端的过程中，项目中还是会存在直接使用绝对路径的情况，我们需要把图片路径修改成编译后的地址。

修改后：

 wujie：框架已处理，默认将相对地址转换成绝对地址。

 micro-app：vue3中需要配置publicPath补全资源路径：

步骤1: 在子应用src目录下创建名称为public-path.js的文件，并添加如下内容：

步骤2: 在子应用入口文件的最顶部引入public-path.js

 其实在选择框架的时候，兼容性往往是一个优先考虑的方向，所以我们这里也来对比一下两个框架之间的兼容性。

 wujie：子应用的dom在webcomponent中，运行环境在iframe中，iframe对dom的操作通过proxy来代理到webcomponent上，而webcomponent和proxy，IE都无法支持.框架会自动对浏览器进行判断，用Object.defineProperty替换proxy来做代理的方案，以解决兼容性的问题。

 micro-app：依赖于CustomElements和Proxy两个较新的API。Proxy暂时没有做兼容，所以对于不支持Proxy的浏览器无法运行micro-app。

 wujie和micro-app都是使用webcomponent相关的API，可以通过引入polyfill进行兼容。由此可见wujie的兼容性方案更胜一筹。

 由于每个子应用的渲染都是一个完整的html页面，所以我们从一个完整页面的渲染过程来分析两者之间的性能差异，大致过程是http请求、js代码执行、dom渲染。由于子应用是一样的，所以http请求这块不在我们的比较范围之内。js代码执行的对比中，我们只对比开始进行JS代码执行的时间，过程中执行的代码都是一样的，没有必要进行对比。

 话不多说，直接上样本进行测试，我选择了两个子应用，一个是简单的页面，一个是比较多图表的页面：

 通过谷歌浏览器的performance分析

 wujie：

 micro-app：

 我把两个性能图片放在一起对比。震惊，我都差点以为自己弄错图片了，基本是惊人的一致加载速度。经过对比，两个开始加载子应用的时间相差20ms左右，最终两者渲染出来的dom只相差200ms左右，跟我一开始预测的结果一样，确实micro-app的性能相对来说好一点。(简单页面对比图片就不放出来了，dom渲染时间对比也是micro-app快将近200ms)

 由此可得出结果：

 wujie是相对来说比较新的框架(可能坑比较多还没被人踩完)，性能上相对micro-app稍微差一点，不过这个微小的差距还是可以忽略不计的。总的来说，为了更加快地改造成微前端项目，个人还是比较推荐使用wujie的。

 写这篇文章的意义不是在于区分这两个框架的好坏，而是为了验证自己的理论是否正确并且做一个更加全面的比较方便读者选择。每个框架的发布都是社区爱好者的一份贡献，只有更加适合自己的框架，而没有不好的框架这种说法。